Single sign-on for managed mobile devices using kerberos

ABSTRACT

Disclosed are various examples for single-sign on by way of managed mobile devices using Kerberos. For example, a certificate is received from a client device. In response, a Kerberos ticket-granting ticket is generated and sent to the client device. A request for a service ticket is later received from the client device. The request for the service ticket can include the ticket-granting ticket. The service ticket is then generated and sent to the client device. Subsequently, the service ticket is received from the client device and a security assertion markup language (SAML) response is sent to the client device in reply. The SAML response can provide authentication credentials for a service provider associated with the service ticket.

CROSS-REFERENCE TO RELATED APPLICATIONS

This continuation-in-part application claims priority to, and thebenefit of, U.S. patent application Ser. No. 14/739,975, entitled“SINGLE SIGN-ON FOR MANAGED MOBILE DEVICES” and filed on Jun. 15, 2015.This application is also related to U.S. patent application Ser. No.14/739,980, entitled “SINGLE SIGN-ON FOR MANAGED MOBILE DEVICES” andfiled on Jun. 15, 2015, under Attorney Docket Number W205.02. Thisapplication is further related to U.S. patent application Ser. No.14/739,983, entitled “SINGLE SIGN-ON FOR UNMANAGED MOBILE DEVICES” andfiled on Jun. 15, 2015 under Attorney Docket Number W204.01. Inaddition, this application is related to U.S. patent application Ser.No. 14/739,972, entitled “SINGLE SIGN-ON FOR UNMANAGED MOBILE DEVICES”and filed on Jun. 15, 2015 under Attorney Docket Number W204.02. Each ofthese applications is incorporated herein by reference in its entirety.

BACKGROUND

Users may have many different accounts for a multitude of applicationsand services. Examples of applications and services may include socialnetworking services, file sharing services, email services, voicecommunication services, office productivity services, task trackingservices, and still others. A user may have to establish a correspondingusername and password to authenticate for each account. This becomes adifficult and inconvenient practice where numerous accounts areinvolved. Accordingly, users may set weak passwords that are short orotherwise easy to remember, share passwords among multiple accounts, usethird-party password managers, or engage in other practices that mightbe regarded as insecure.

The concept of identity federation arose as a solution to this problem.Under identity federation, a user establishes an account with afederated identity provider. To this end, the user specifies a singleset of security credentials. The federated account is then linked to amultiplicity of applications and services that are provided by otherorganizations. When the user seeks to access applications and servicesthat are linked to the federated account, the user can simply providethe single username, password, or other credentials of the federatedaccount for authentication. In like manner, an organization such as anenterprise may use a directory service such as ACTIVE DIRECTORY byMICROSOFT CORPORATION in order to provide a single log-in for each ofmultiple applications and services of the organization.

Despite the availability of identity federation, the end user experiencemay still be suboptimal. Even assuming that users are able to employ asingle federated account for multiple applications and services, theusers may be required to enter the federated account credentialsseparately. For example, suppose that a user logs in with a socialnetworking application provided by a social networking service providerthat is also a federated identity provider. Subsequently, the user maywant to use a file sharing application that is linked to the federatedidentity provider. The user may then have to supply the same usernameand password that was previously entered for the social networkingapplication. Repetitively entering these security credentials for eachapplication and service may frustrate users.

BRIEF DESCRIPTION OF THE DRAWINGS

Many aspects of the present disclosure can be better understood withreference to the following drawings. The components in the drawings arenot necessarily to scale, with emphasis instead being placed uponclearly illustrating the principles of the disclosure. Moreover, in thedrawings, like reference numerals designate corresponding partsthroughout the several views.

FIG. 1 is a drawing illustrating an example scenario of the disclosure.

FIG. 2 is a drawing of a networked environment according to variousexamples of the disclosure.

FIG. 3 is a sequence diagram illustrating an example componentinteraction according to various examples of the present disclosure.

FIGS. 4-8 are flowcharts illustrating examples of functionalityaccording to various examples of the present disclosure.

FIG. 9 is a sequence diagram illustrating an example implementation ofan embodiment of the present disclosure using Kerberos.

DETAILED DESCRIPTION

The present disclosure relates to providing a single sign-on experiencefor users of mobile devices. With a single sign-on experience, a userenters or obtains a single set of security credentials for an accountand, upon authentication, the user is able to access multiple differentapplications and services that are linked to that account. Multi-factorauthentication can also be employed where the user is required toprovide a combination of knowledge, possession, or biometricauthentication factors. As contemplated herein, the term “singlesign-on” can include scenarios in which a user is required to re-entersecurity credentials due to session timeouts, inactivity periods,suspicious activities, or other events that could cause authenticationof the user to be doubted.

In the context of a web browser, a single sign-on experience can beenabled by way of cookies. In response to a user logging in with afederated identity provider, a cookie can be stored on the user's devicethat contains a token indicating authentication. When the user lateraccesses another network site that supports authentication by way of thefederated identity provider, the cookie is presented and the token canbe exchanged for a site-specific token. Consequently, the user does nothave to log in again to access the network site.

However, the single sign-on design paradigm from the browser contextdoes not function in the context of mobile applications. Although mobileapplications can invoke web views, cookies that are part of a web viewinvoked within a mobile application cannot be accessed in other mobileapplications or by a browser. Even assuming that a user logs into afederated account by way of a first mobile application, the cookies andapplication tokens that indicate successful authentication are not madeavailable to a second mobile application because they can have separatewebviews. As will be described, various implementations of the presentdisclosure facilitate single sign-on within mobile applications andother applications that embody this limitation. Moreover, according tothe present disclosure, the requirement to use a particular softwaredevelopment kit (SDK) for each application in order to implement singlesign-on can be rendered unnecessary.

Specifically, in the present disclosure, examples are disclosed thatenable a single sign-on experience for mobile devices that are managed.With reference to FIG. 1, shown is a pictorial diagram of an examplesingle sign-on scenario 100. At 101, a user launches a managementapplication that can manage applications upon the user's mobile device.The management application can be a native mobile application or aweb-based management application accessed from a browser. The managementapplication renders a user interface configured to receive logininformation for a device management service. Specifically in thisexample, the user interface includes a form configured to receive ausername and a password. Other security credentials or authenticationfactors can be elicited in other examples. After the user enters theinformation, the user selects a log-in entry component.

Upon entering correct log-in information, the user is authenticated, andthe user interface can then be updated to indicate to the user that thelog-in was successful at 102. Subsequently, the user can launch oraccess other managed applications on the mobile device, such as a socialnetworking application at 103, an email application at 104, or a filesharing application 105. These applications can communicate with anexternal service. Because the user has already been authenticatedthrough the device management application, these applications indicatethat the user is already authenticated. Consequently, the user does nothave to provide login information for the applications separately, andthe user is able to use the services accessed through the respectiveapplications.

With reference to FIG. 2, shown is a networked environment 200 accordingto various examples. The networked environment 200 includes a clientdevice 203, a device management service 204, an identity provider 206, akey distribution center (KDC) 207, a certificate authority 208, aplurality of service providers 209 a . . . 209N, and an onlinecertificate status protocol (OSCP) service 210, which can be in datacommunication with one another over the network 212. The network 212includes, for example, the Internet, one or more intranets, extranets,wide area networks (WANs), local area networks (LANs), wired networks,wireless networks, other suitable networks, or any combination of two ormore such networks. For example, the networks can include satellitenetworks, cable networks, Ethernet networks, and other types ofnetworks.

The device management service 204, the identity provider 206, the KDC207, the certificate authority 208, the service providers 209, and theOCSP service 210 can include, for example, a server computer or anyother system providing computing capabilities. Alternatively, the devicemanagement service 204, the identity provider 206, the KDC 207, thecertificate authority 208, the service providers 209, and the OCSPservice 210 can employ multiple computing devices that can be arranged,for example, in one or more server banks, computer banks, or otherarrangements. The computing devices can be located in a singleinstallation or can be distributed among many different geographicallocations. For example, the device management service 204, the identityprovider 206, the KDC 207, the certificate authority 208, the serviceproviders 209, and the OCSP service 210 can include multiple computingdevices that together form a hosted computing resource, a grid computingresource, or any other distributed computing arrangement. In some cases,the device management service 204, the identity provider 206, the KDC207, the certificate authority 208, the service providers 209, and theOCSP service 210 can operate as at least a portion of an elasticcomputing resource where the allotted capacity of processing, network,storage, or other computing-related resources can vary over time. Thedevice management service 204, the identity provider 206 the KDC 207,the certificate authority 208, the service providers 209, and the OCSPservice 210 can also include or be operated as one or more virtualizedcomputer instances. Generally, the device management service 204, theidentity provider 206 the KDC 207, the certificate authority 208, theservice providers 209, and the OCSP service 210 can be operated inaccordance with particular security protocols such that they areconsidered trusted computing environments.

The device management service 204 can manage or oversee the operation ofmultiple client devices 203. In some examples, an enterprise, such asone or more companies or other organizations, can operate the devicemanagement service 204 to oversee or manage the operation of the clientdevices 203 of employees, contractors, or other users within anenterprise environment. In this sense, the client devices 203 caninclude managed devices that are managed by the device managementservice 204.

To facilitate management of client devices 203, the device managementservice 204 can establish a secure communications channel with theclient devices 203 (e.g., a mobile device management channel, or MDMchannel). The device management service 204 can establish the securecommunications channel by creating a secure communication link with theclient device 203. A secure communication link can be established usingMDM application programming interfaces (APIs) that are provided by anoperating system executed by the client device 203. In some examples,the secure communications channel can be established using a pushnotifications framework or notification service provided by an operatingsystem ecosystem associated with the client device 203 that allows forcommunications between the device management service 204 and a clientdevice 203 over the network 212 that are encrypted using a digitalcertificate.

The client device 203 can be enrolled as a managed device with thedevice management service 204 through APIs provided by the operatingsystem. The enrollment process can include authentication of a user'scredentials. Upon authentication of a user's credentials by the devicemanagement service 204, the client device 203, using the MDM APIs of theoperating system, can enroll the client device 203 as a managed deviceso that various management functions can be securely performed over thesecure communications channel.

Examples of management functions can include commands to erase certaindata from the client device 203, commands to install certainapplications or application updates, commands to lock a client device203 or activate a display lock feature, a command to remotely perform afactory reset of the client device 203, or other management functions.Additionally, data can be securely transmitted through the securecommunications channel to the client device 203 or applications executedby the client device 203.

Additionally, the operating system of the client device 203 can alsoprovide the ability to create access-restricted storage that isassociated with particular applications installed on the client device203. Access-restricted storage can be associated with multipleapplications that are installed on the client device 203 through thesecure communications channel. In some scenarios, applications that aresigned by a common certificate can be provided access to theaccess-restricted storage of each other, whereas applications that arenot signed by the certificate do not have access to theaccess-restricted storage of other applications. Additionally, thedevice management service 204 can transmit data to the client device 203over the secure communications channel that can be stored in theaccess-restricted storage such that it is accessible by certainapplications and inaccessible to other applications that are installedon the client device 203.

The secure communications channel can be encrypted or secured using adigital certificate that is associated with the client device 203, thedevice management service 204, or an enterprise with which the clientdevice 203 is associated. In one scenario, the device management service204 can obtain a security certificate, such as a secure sockets layer(SSL) certificate, that is unique to a particular enterprise with whicha client device 203 is associated. In one example, an administratorassociated with the enterprise can provide a certificate to the devicemanagement service 204 using an administrator console or otherfunctionality with which a certificate can be uploaded. The certificatecan also be signed by a certificate authority, which can in some casesbe operated by the device management service 204. The device managementservice 204 can encrypt or secure the secure communications channelusing the certificate so that the secure communications channel is asecure communication link over the network 212 through which data can besent to the client device 203.

Additionally, the device management service 204 can specify that datasent through the secure communications channel can only be accessed bycertain applications installed on the client device 203. Theapplications that can access data sent through the secure communicationschannel can also be restricted in how certain data can be manipulated,viewed or handled on the client device 203. For example, an applicationinstalled on the client device 203 can be coded to restrict the abilityof a user to capture, share, or otherwise remove data from the clientdevice 203 that is received through the secure communications channel.

The device management service 204 can also facilitate ensuring thatclient devices 203 that are administered by the device managementservice 204 are operating in compliance with various compliance rules.In one scenario, the device management service 204 can issue managementcommands that instruct a client device 203 to take a particular actionwith respect to a compliance rule. For example, if a client device 203is designated as lost or stolen, the device management service 204 canissue a command instructing the client device 203 to erase data andapplications that were previously sent to the client device 203 throughthe secure communications channel or other communication links andotherwise stored on the client device 203. The device management service204 can also obtain data from a third party computing environment, suchas an application, a security code, authentication token, or other data.As another example, if the device management service 204 determines thata client device 203 has violated a compliance rule with respect tohaving unauthorized modifications or unauthorized applications installedon the client device 203, the device management service 204 can issue acommand instructing the client device 203 to erase data and applicationsstored on the client device 203. As a further example, the devicemanagement service 204 can also issue a command instructing the clientdevice 203 to activate a display lock of the client device 203 thatrequires a user to enter a personal identification number (PIN) in orderto use the client device 203.

The data stored in the management data store 213 and available to thedevice management service 204 includes, for example, authenticationdata, compliance rules, device data, and potentially other data. Theauthentication data can include data used to verify one or more securitycredentials presented by a user for authentication. To this end, securecertificates can be stored and then be made available to the clientdevice 203 that has been authenticated in order to encrypt the securecommunications channel and/or for other functions.

Within the context of an enterprise, compliance rules include one ormore rules that, when violated, can cause the device management service204 to issue a management command. Compliance rules can include a listof unauthorized hardware functions, software functions, or applicationsthat potentially pose a threat to enterprise data or to the use ofenterprise applications. As noted above, if client device 203 falls outof compliance with one or more compliance rules, a management commandcan be transmitted to the client device 203 instructing the clientdevice 203 to perform one or more actions specified by the compliancerule. Alternatively, a compliance rule can also reside on the clientdevice 203, which can self-enforce compliance rules. The management datastore 213 can also include user account data. User account data caninclude information with which a user account can be authenticated, suchas user credentials. User account data can also include data such asemail, contact, calendar data, documents, files or other data that isassociated with a user account.

Device data can represent data stored in the management data store 213that is associated with client devices 203 that are enrolled with thedevice management service 204 as managed devices. Device data caninclude a unique device identifier associated with the client device203, device policies that are associated with a particular client device203, status information associated with a particular client device 203,and other data that facilitates management of the client device 203 bythe device management service 204. Device data can also include userdata that is synchronized with a particular client device 203. A useraccount can be associated with multiple client devices 203. Differentclient devices 203 associated with a user account can have differentuser account data stored thereon. For example, a user's smartphone canhave a certain number of documents or email messages stored on thedevice, whereas the user's laptop or tablet can have varying amounts oftypes of user account data stored on the device.

The identity provider 206 can provide a federated identity service onbehalf of the service providers 209. To this end, the identity provider206 can be in communication with an identity data store 215 that storesinformation associated with user identities. This information caninclude, for example, usernames, security credentials, biometricidentity information, authorized client applications, unauthorizedclient applications, authorized client devices 203, unauthorized clientdevices 203, and so on. As will be described, users are able toauthenticate by way of the identity provider 206 in order to accessservices provided by the multiple service providers 209. The identityprovider 206 can include a plurality of platform adapters 216 tofacilitate platform-specific authentication on different clientplatforms, such as IOS, ANDROID, WINDOWS, and so on.

The KDC 207 can authenticate a client device 203 according to a versionof the Kerberos protocol. The KDC 207 can be configured to issue aticket-granting ticket, which is time-stamped, and encrypt it using thecredentials supplied by the client device 203. The KDC 207 can alsoissue service tickets to client devices 203 in response to receiving apreviously issued ticket-granting ticket.

The certificate authority 208 generates and issues digital certificatesto computing devices, such as client devices 203. The certificateauthority 208 can also track which computing device (e.g., client device203) a particular certificate has been issued to. The certificateauthority 208 can also revoke a certificate by marking it as invalid andpublishing a certificate revocation list to notify other services orcomputing devices that a previously issued certificate is no longervalid. Digital certificates issued by the certificate authority 208 canbe used to certify ownership of public or private cryptographic keys inorder to facilitate authentication of the identity of a client device203 or its user, facilitate authentication of a server or serviceapplication (e.g., a service provider 209), and to establish encryptedcommunications between two or more computing devices.

The service providers 209 provide corresponding services for clientapplications. The services can include, for example, social networkingservices, email services, voice communication services, enterpriseinformation management services, productivity services, game services,and so on. In some examples, one or more of the service providers 209can authenticate users separately from the identity provider 206,thereby giving users the option to log in either with the identityprovider 206 or with the service provider 209 directly.

The service providers 209 and the identity provider 206 can communicatewith the client device 203 over the network 212 by way of hypertexttransfer protocol (HTTP), simple object access protocol (SOAP),representational state transfer (REST), and/or other protocols.

The OCSP service 210 can provide the revocation status of a certificateissued by the certificate authority 208 in response to a request thatcomplies with a version of the online certificate status protocol(OCSP). Accordingly, the OCSP service 210 may periodically retrieve acertificate revocation list (CRL) from the certificate authority 208 inorder to track which certificates issued by the certificate authority208 are currently valid. The OCSP service 210 can then compare theidentifier of a certificate included in an OCSP request with the CRLretrieved from the certificate authority 208 to determine the currentstatus of the certificate identified in the OCSP request and provided anappropriate response.

The client device 203 can represent a processor-based system, such as acomputer system, that can be embodied in the form of a desktop computer,a laptop computer, a personal digital assistant, a cellular telephone, asmartphone, a set-top box, a music player, a web pad, a tablet computersystem, a game console, an electronic book reader, or any other devicewith like capability. The client device 203 can include a display 218that includes, for example, one or more devices such as liquid crystaldisplay (LCD) displays or other types of display devices. The clientdevice 203 can also be equipped with networking capability or networkinginterfaces, including a localized networking or communication capabilitysuch as an NFC capability, RFID read and/or write capability, amicrophone and/or speaker, or other localized communication capability.

The client device 203 can execute various applications, such as anoperating system 219, a management application 221, a plurality ofclient applications 224 a . . . 224N, and other applications, services,or processes. The operating system 219 can provide access to hardware orsoftware resources of the client device 203 to the managementapplication 221 or one or more client applications 224 a . . . 224N. Theoperating system 219 can also provide various functions to themanagement application 221 or client applications 224 a . . . 224N.Examples of operating systems 219 include various versions of APPLE IOS,GOOGLE ANDROID, and MICROSOFT WINDOWS.

The management application 221 can receive security credentials from auser and to authenticate with the device management service 204. Uponauthentication with the device management service 204, the managementapplication 221 is able to obtain management credentials 225, which inturn allow the client applications 224 to request identity assertionsfrom the identity provider 206 in order to authenticate the clientapplications 224 with the respective service providers 209 as will bedescribed. Although described as an application, it is understood thatthe management application 221 can be an integral component of theoperating system 219 of the client device 203. Also, in some scenarios,the management credentials 225 can be provisioned directly to theoperating system for all client applications 224 to use. This can beperformed under iOS using either a certificate profile that is installedin a managed certificate keychain or a combination of a certificate anda Kerberos profile together. Rather than being stored in the managementapplication 221, the management credentials 225 can be stored in theoperating system itself in these scenarios. Various access rules 226 canrestrict which client applications 224 are permitted to use themanagement credentials 225 for authenticating with identity providers206. In various implementations, the access rules 226 can be maintainedand enforced by the identity provider 206.

An identity assertion in security assertion markup language (SAML), forexample, contains a packet of security information that serviceproviders 209 use to make access control decisions. SAML supports threetypes of statements: authentication statements, attribute statements,and authorization decision statements. Authentication statements assertto the service provider 209 that the client device 203 authenticatedwith the identity provider 206 at a particular time using a particularmethod of authentication. An attribute statement asserts that a clientdevice 203 is associated with certain attributes. An authorizationdecision statement asserts that a client application 224 is permitted toperform a certain action relative to a resource offered by the serviceprovider 209. Extensible access control markup language (XACML) and/orother languages can be employed.

The client applications 224 correspond to a variety of applications thatare employed to access services provided by the service providers 209.The client applications 224 can include a web view component, wherebythe client applications 224 interact with the service providers 209 toobtain network content by way of hypertext transfer protocol (HTTP)requests and responses. However, unlike a browser that is used to accessvarious web-based applications, cookies set through one clientapplication 224 cannot be accessed by another client application 224.The client applications 224 and the management application 221 canindividually render a respective user interface 227 upon the display218.

Turning now to FIG. 3, shown is a sequence diagram 300 illustrating oneexample of interaction between the client application 224, themanagement application 221, the device management service 204, theservice provider 209, and the identity provider 206. Functionalityattributed to the client application 224, the management application221, the device management service 204, the service provider 209, andthe identity provider 206 can be implemented in a single process orapplication or in multiple processes or applications. The separation orsegmentation of functionality as discussed herein is presented forillustrative purposes only.

Beginning with step 303, the client application 224 sends an accessrequest to the service provider 209. At step 306, the service provider209 sends a redirection back to the client application 224 that causesclient application 224 to redirect the access request to the identityprovider 206. At step 309, the client application 224 sends an identityassertion request to the identity provider 206. At step 312, theidentity provider 206 detects the type of client application 224 and theplatform and responds by requesting authentication by way of amanagement credential 225 for the specific platform. This can correspondto a certificate challenge or a Kerberos challenge. At step 315, theclient application 224 requests the management credential 225 from themanagement application 221.

At step 318, the management application 221 obtains one or more securitycredentials from the user by way of a user interface 227. This step canoccur upon initial launch of the management application 221, with thecredentials being stored in various scenarios locally by the managementapplication 221 or on a cloud server, such as identity data store 215,to provide a single sign-on experience for future accesses. At step 321,the management application 221 sends an authentication request to thedevice management service 204. The authentication request can specifythe security credentials obtained from the user. At step 324, the devicemanagement service 204 sends the management credential 225 to themanagement application 221. At step 327, the management application 221returns the management credential 225 to the client application 224.

At step 330, the client application 224 uses the management credential225 to authenticate with the identity provider 206. The identityprovider 206 returns the identity assertion to the client application224 at step 333. At step 336, the client application 224 provides theidentity assertion to the service provider 209. At step 339, the serviceprovider 209 verifies the identity assertion. The service provider 209generates a session token, such as an OAuth token, and returns thesession token at step 342.

Single sign-on is thereby implemented for subsequent client applications224 or for the client application 224 seeking to authenticate withanother service provider 209. Thus, the process can repeat again for theclient applications 224 a . . . 224N. However, once the user isauthenticated with the management application 221 for the purpose ofauthenticating client application 224 a, the user need not entersecurity credentials again for authenticating client application 224 b,unless perhaps due to inactivity or other events that could cause theidentity of the user to be in question. Steps 315, 318, 321, 324, and327 can be executed during the initial access to the client application224 a, but these steps can subsequently be omitted for access to theclient application 224 b since the management application 221 will havealready obtained the management credential 225. Alternatively, thecredentials can be stored by the management application 221 andautomatically entered at step 318 without user input. During the singlesign-on process, the user interface can remain stable to avoid“flipping” back and forth, making the process seamless to a user.

Moving on to FIG. 4, shown is a flowchart that provides one example ofthe operation of an identity provider 206. As an alternative, theflowchart of FIG. 4 can be viewed as depicting an example of elements ofa method implemented in a computing device. Functionality attributed tothe identity provider 206 can be implemented in a single process orapplication or in multiple processes or applications. The separation orsegmentation of functionality as discussed herein is presented forillustrative purposes only.

Beginning with step 403, the identity provider 206 receives an identityassertion request from a client application 224. The client application224 has been redirected to the identity provider 206 by a serviceprovider 209. The redirection can be performed, for example, by way of ahypertext transfer protocol (HTTP) redirection response having statuscode 302. At step 406, the identity provider 206 in some scenarios candetermine that the client application 224 corresponds to a mobileapplication web view instead of a browser. For example, the clientapplication 224 can send a user-agent string to the identity provider206 within an HTTP request. The user-agent string can identify whetherthe request originates from a specific browser or from a web view of anative application. With a browser, an alternative form of singlesign-on for identity federation can be used, as cookies set by theidentity provider 206 can be accessed by different service providers209. However, with mobile applications using webviews, the cookiescannot be shared among different applications without the use ofspecialized software development kits (SDKs). In some cases, theidentity provider 206 can be configured to deny access if the clientapplication 224 is a browser or an unmanaged application.

At step 407, the identity provider 206 determines a platform of theclient device 203. The identity provider 206 can determine the platformalso by examining the user-agent string of the HTTP request. Forexample, the identity provider 206 can determine that the client device203 corresponds to IOS, ANDROID, WINDOWS, BLACKBERRY, or other platformsbased at least in part on corresponding identifiers contained in theuser-agent string.

At step 408, the identity provider 206 requests authentication bymanagement credential 225 based at least in part on the detectedplatform of the client device 203. Specifically, the identity provider206 can request authentication using a platform-specific managementcredential 225 after querying a table of platforms based at least inpart on information provided by the client device 203. Different typesof security credentials and certificates can be used depending on theplatform of the client device 203. For example, the managementcredential 225 can include a secure certificate, a Kerberos profile, orother credentials. Accordingly, to allow single sign-on from differingplatforms, the platform adapter 216 can request the type of managementcredential 225 that is appropriate for the client device 203 that isrequesting access. For example, when the platform is IOS, a platformadapter 216 corresponding to an IOS-specific certificate adapter orKerberos adapter can be used, such as an esso profile. When the platformis ANDROID, a platform adapter 216 corresponding to a certificateadapter can be used. As additional examples, the OSX operating systemcan use a keychain, and WINDOWS 10 can use account provider credentials.The request for authentication can be performed by returning an HTTPresponse having status code 401, indicating that authorization isrequired. Further, the HTTP response can specifically requestauthentication by a particular protocol, such as the Kerberos protocol,through the use of a management credential 225.

At step 410, the identity provider 206 determines whether the clientdevice 203 corresponds to a managed device. If the client device 203 isa managed device, the authentication of step 408 would completeproperly. If the authentication of step 408 fails, the client device 203can be presumed to be unmanaged. If the client device 203 does notcorrespond to a managed device, the identity provider 206 continues tostep 411. If the client device 203 does correspond to a managed device,the identity provider 206 moves to step 412.

At step 415, the identity provider 206 receives data associated with orgenerated by the management credential 225. At step 418, the identityprovider 206 determines that the presented management credential 225 isvalid for the requested identity assertion. The identity provider 206can verify whether the management credential 225 is permitted to be usedto authenticate specific client applications 224 or for specific serviceproviders 209. At step 421, if the management credential 225 isdetermined to be valid, the identity assertion is generated and sent tothe client application 224. The identity assertion can include securityassertion markup language (SAML), extensible access control markuplanguage (XACML), or other data. Thereafter, the process proceeds tocompletion.

If, instead, the client device 203 is not a managed device, at step 411,the identity provider 206 determines whether the client application 224is permitted to execute on an unmanaged device according to a policy. Ifthe client application 224 is not permitted to execute on an unmanageddevice, the identity provider 206 moves from step 411 to step 424 andblocks the authentication of the client application 224 and anunauthorized message may be returned. Thereafter, the process proceedsto completion.

If the client application 224 is permitted to execute on an unmanageddevice, the identity provider 206 moves from step 411 to step 427, andthe identity provider 206 requests authentication by user-suppliedcredentials, such as a username and password, biometric credentials,multi-factor credentials, and so on. At step 430, the identity provider206 receives and validates the user-supplied credentials from the clientapplication 224. The identity provider then moves to step 421, where theidentity assertion is generated and sent to the client application 224.The identity assertion can include security assertion markup language(SAML), extensible access control markup language (XACML), or otherdata. Thereafter, the process proceeds to completion.

Continuing on to FIG. 5, shown is a flowchart that provides one exampleof the operation of a device management service 204. Functionalityattributed to the device management service 204 can be implemented in asingle process or application or in multiple processes or applications.The separation or segmentation of functionality as discussed herein ispresented for illustrative purposes only.

Beginning with step 501, the device management service 204 receives anenrollment request from a client device 203. For example, a user cannavigate to a certain uniform resource locator (URL) in a browser, themanagement application 221 can be installed on the client device 203,and a user can accept the terms of the enrollment. Then, aplatform-specific management certificate can be sent to the managementapplication 221. The platform-specific management certificate can bereceived within a profile which the client device 203 installs in aprofile store as the management profile.

In step 503, the device management service 204 receives anauthentication request from the management application 221 of the clientdevice 203. The request can specify one or more security credentials,such as usernames, passwords, biometric identification, one-timepasswords, and so on. At step 506, the device management service 204determines that the security credentials that have been presented arevalid. If the security credentials are not valid, an error can begenerated.

At step 509, the device management service 204 sends one or moremanagement credentials 225 to the client device 203. The managementcredentials 225 can be generated by a certificate authoritycorresponding to the device management service 204. The managementcredentials 225 can be employed to create a secure communicationschannel between the device management service 204 and the managementapplication 221 for device management purposes. Thereafter, the processproceeds to completion.

With reference to FIG. 6, shown is a flowchart that provides one exampleof the operation of a management application 221. Functionalityattributed to the management application 221 can be implemented in asingle process or application or in multiple processes or applications.The separation or segmentation of functionality as discussed herein ispresented for illustrative purposes only.

Beginning with step 603, the management application 221 receives asingle sign-on request from a client application 224. For example, theclient application 224 can be prompted to use a management credential225 in order to authenticate with an identity provider 206. At step 606,the management application 221 determines whether the user is alreadyauthenticated. If the user is not already authenticated, the managementapplication 221 moves to step 609 and renders a user interface 227 onthe display 218 that requests one or more security credentials from theuser. At step 612, the management application 221 receives the securitycredentials through the user interface 227. The management application221 continues to step 615. If the user is already authenticated by themanagement application 221, the management application 221 movesdirectly from step 606 to step 615.

At step 615, the management application 221 determines whether theclient application 224 is authorized to receive the managementcredential 225. The management application 221 can make thisdetermination with respect to the access rules 226 or by way ofcommunication with the device management service 204. Examples of accessrules 216 include detecting whether a device is jailbroken, uses apassword of a given length or complexity, is used within a certaingeographic area, has certain applications installed, has certainhardware devices (e.g., a fingerprint reader), and/or other meets othercriteria relevant to the organization for whom the client device 203 ismanaged. If the client application 224 is not authorized, the managementapplication 221 moves to step 618 and rejects the request. Thereafter,the process proceeds to completion.

If the client application 224 is authorized, the management application221 moves to step 621 and determines whether the management credential225 has been cached in the client device 203. If the managementcredential 225 has been cached, the management application 221 loads themanagement credential 225 from the cache at step 624. At step 625, themanagement application 221 provides the management credential 225 to theclient application 224. Thereafter, the process proceeds to completion.

If the management credential 225 has not been cached, the managementapplication 221 moves from step 621 to step 627 and authenticates withthe device management service 204. To this end, the managementapplication 221 can authenticate using the user-supplied credentials ora session or registration token. At step 630, the management application221 sends a request for the management credential 225 to the devicemanagement service 204. At step 633, the management application 221receives the management credential 225 from the device managementservice 204. At step 625, the management application 221 provides themanagement credential 225 to the client application 224. Thereafter, theprocess proceeds to completion.

Turning now to FIG. 7, shown is a flowchart that provides one example ofthe operation of a client application 224. Functionality attributed tothe client application 224 can be implemented in a single process orapplication or in multiple processes or applications. The separation orsegmentation of functionality as discussed herein is presented forillustrative purposes only.

Beginning with step 703, the client application 224 sends an accessrequest to a service provider 209. At step 706, the client application224 receives a redirection to the identity provider 206. The redirectioncan include a hypertext transfer protocol (HTTP) redirection responsehaving status code 302. At step 709, the client application 224 sends anidentity assertion request to the identity provider 206. At step 712,the client application 224 receives a response requesting authenticationby a management credential 225.

At step 715, the client application 224 obtains the managementcredential 225 from the management application 221. To this end, theclient application 224 can send a request by a local uniform resourcelocator (URL) to the management application 221 and can also receive aresponse from the management application 221 by a local URL. The localURL used to invoke the management application 221 can include callbackinformation such as a scheme name corresponding to the clientapplication 224 so that the management application 221 can identify theclient application 224 and return the requested management credential225.

At step 718, the client application 224 sends data associated with orgenerated by the management credential 225 to the identity provider 206.At step 721, the client application 224 receives an identity assertionfrom the identity provider 206. The identity assertion can correspond toa security assertion markup language (SAML) assertion or anotherassertion. At step 724, the client application 224 authenticates withthe service provider 209 using the identity assertion. At step 727, theclient application 224 receives a session token from the serviceprovider 209. For example, the session token can correspond to an OAuthtoken. Subsequently, at step 730, the client application 224 canauthenticate with the service provider 209 to access resources.Thereafter, the process proceeds to completion.

Referring next to FIG. 8, shown is a flowchart that provides one exampleof the operation of a service provider 209. As an alternative, theflowchart of FIG. 8 can be viewed as depicting an example of elements ofa method implemented in a computing device. Functionality attributed tothe service provider 209 can be implemented in a single process orapplication or in multiple processes or applications. The separation orsegmentation of functionality as discussed herein is presented forillustrative purposes only.

Beginning with step 803, the service provider 209 receives an accessrequest from a client application 224. The service provider 209 thencorrelates this access request to the use of the identity provider 206for authentication. At step 806, the service provider 209 sends aredirection response to the client application 224. This can include ahypertext transfer protocol (HTTP) redirection response with status code302. The redirection response can redirect the client application 224 tothe identity provider 206. The redirection response can include securityassertion markup language (SAML) that requests an identity assertion.

At step 809, the service provider 209 receives the identity assertionfrom the client application 224. At step 812, the service provider 209verifies the identity assertion. For example, the identity assertion caninclude an authentication token generated by the identity provider 206,and the service provider 209 can confirm that the authentication tokenis authentic.

At step 815, the service provider 209 generates a session token. At step818, the service provider 209 sets a session cookie including thesession token with the client application 224. At step 821, the serviceprovider 209 provides service access to the client application 224 basedat least in part on the client application 224 presenting the sessiontoken, by way of a uniform resource locator (URL) or session cookie.Thereafter, the process can proceed to completion.

Turning to FIG. 9, shown is a sequence diagram 900 illustrating oneexample of interaction between the client application 224, the operatingsystem 219, the certificate authority 208, the identity provider 206,the platform adaptor 216, the KDC 207, the OCSP service 210, and theservice provider 209. Functionality attributed to the client application224, the operating system 219, the certificate authority 208, theidentity provider 206, the platform adaptor 216, the KDC 207, the OCSPservice 210, and the service provider 209 can be implemented in a singleprocess or application or in multiple processes or applications. Theseparation or segmentation of functionality as discussed herein ispresented for illustrative purposes only.

Beginning with step 903, the management application 221 can enroll theclient device 203 with the certificate authority 208. Enrollment of theclient device 203 with the certificate authority 208 can occur as partof the process for enrolling the client device 203 with the devicemanagement service 204. As part of the enrollment process, the clientdevice 203 can provide the certificate authority 208 with a deviceidentifier, which allows the certificate authority 208 to track whichcertificates have been issued to the client device 203.

Proceeding to step 906, the certificate authority 208 can provision acertificate for the client device 203 and can specify a KDC 207 to beused by the client device 203. To provision the certificate, thecertificate authority 208 can generate the certificate to be used by theclient device 203, cryptographically sign the certificate to verify itsauthenticity, and send the newly generated and signed certificate to theclient device 203 for future use. The management application 221 canstore the provisioned certificate along with any other managementcredentials 225 stored on the client device 203. The certificateauthority 208 can also send the identity (e.g. URL or IP address) of theKDC 207 to the client device 203 to be used for future Kerberosauthentication using the provisioned certificate.

Moving on to step 909, the client application 224 can be launched. Theclient application 224 can be launched in response to a user interactionwith the client device 203 or in response to a request or command fromanother application (e.g., one application initiating execution ofanother application).

Referring next to step 913, the client application 224 can send arequest for authentication to the service provider 209. Theauthentication request may include the identity of the client device203, the client application 224, and potentially other information. Theauthentication request can be sent using a variety of protocols. Forexample, the authentication request can be sent to the service provider209 in compliance with a version of the hypertext transfer protocol(HTTP).

Proceeding to step 916, the service provider 209 can send a response tothe client application 224 that redirects the client application 224 tothe identity provider 206. For example, the service provider could sendan HTTP response with a redirect status code (e.g., 301, 302, 303, 307,or 308) that specifies the URL of the identity provider 206. Theresponse can also include a SAML Authentication Request. In these cases,the redirection can be implemented through a SAML HTTP Redirect Binding.In some instances, the SAML Authentication Request can also specify whattypes of authentication schemes (e.g., Kerberos) should be used toauthenticate the client device 203 or client application 224.

Moving on to step 919, the client application 224 can send anauthentication request to the identity provider 206. For example, theclient application 224 could send the SAML Authentication Request it hadpreviously received at step 916 to the identity provider 206 specifiedby the SAML HTTP Redirect Binding.

Referring next to step 923, the identity provider 206 can attempt toauthenticate the client application 224 with the platform adapter 216.For example, the identity provider 206 can supply the informationincluded in the SAML Authentication Request or otherwise supplied by theclient application 224 to the platform adapter 216. If multiple platformadapters 216 are available, then the identity provider 206 may selecteither a default platform adapter 216 or a platform adapter specified inthe SAML Authentication Request (e.g., a platform adapter 216 thatprovides Kerberos authentication). The identity provider 206 can thenwait for the platform adapter 216 to respond to the authenticationattempt of the identity provider 206.

Proceeding to step 926, the platform adapter 216 can determine that theinitial authentication request contains insufficient information toperform Kerberos authentication. The platform adapter 216 therefore cansend a Kerberos challenge to the client application 224. In someimplementations, the initial authentication request will be expected tofail because a Kerberos authentication has not yet been performed.

Moving on to step 929, the operating system 219 (e.g., iOS) canintercept the Kerberos challenge. The operating system 219 can then sendthe certificate previously provisioned in step 906 to the KDC 207previously configured in step 906 in order to obtain a service ticket topresent to the platform adapter 216 in response to the Kerberoschallenge.

Referring next to step 933, the KDC 207 can determine whether thecertificate provided by the operating system 219 has been revoked. Forexample, the KDC 207 can send the certificate's fingerprint or otheridentifying information about the certificate to an OCSP service 210 toverify that the certificate is still valid. However, in alternativeimplementations, the KDC 207 could request a certificate revocation listfrom the certificate authority 208 and determine whether the certificateis included in the certificate revocation list.

Proceeding to step 936, the OCSP service 210 can determine therevocation status of the certificate. For example, the OCSP service 210could compare the certificate's unique identifier to a list ofidentifiers of revoked certificates previously issued by the certificateauthority 208. As another example, the OCSP service 210 could comparethe certificate's unique identifier to a list of identifiers ofcertificates issued by the certificate authority 208 that are known tostill be valid. If the certificate is still valid, the OCSP service 210can send a response to the KDC 207 indicating that the certificate isstill valid.

Moving on to step 939, the KDC 207 can provide a ticket-granting ticketto the operating system 219 based on the validation of the certificateby the OCSP service 210. Referring next to step 943, the operatingsystem 219 can send a request for a service ticket to the KDC 207. Theservice ticket may be associated with one or more service providers 209,allowing a client device 203 that has the service ticket to access eachof the associated service providers 209 for as long as the serviceticket remains valid.

Proceeding to step 946, the KDC 207 can generate a service ticket andcan provide it to the operating system 219. To generate the serviceticket, the KDC 207 first determines that the ticket-granting ticketreceived from the operating system 219 is valid (e.g., has not expiredor was previously issued by the KDC 207 or another trusted KDC 207). TheKDC 207 can also check any access permissions associated with theticket-granting ticket (e.g., whether the ticket-granting ticketauthorized to receive a service ticket for access to a particularservice provider 209). Assuming that the ticket-granting ticket is validand the access permissions associated with ticket-granting ticket permitthe client device 203 to access the service provider 209, the KDC 207generates the service ticket and sends it to the operating system 219.Moving on to step 949, the operating system 219 provides the serviceticket to the platform adapter 216.

Referring next to step 953, the platform adapter 216 receives andvalidates the service ticket. For example, the platform adapter 216 canverify the validity of the service ticket (e.g., issued by authorizedKDC 207, has not expired, or similar checks) and whether the serviceticket permits access to the request service provider 209. If theservice ticket is valid and can be used to access the service provider209, the platform adapter 216 then responds (e.g. using a functioncallback) to the login request submitted by the identity provider 206indicating that the client application 224 is authenticated andauthorized to access the service provider 209.

Proceeding to step 956, the identity provider 206 sends a SAML responseto the client application 224 granting access to the service provider209. The SAML response may include information that was included in theservice ticket, such as a username or similar identifier, as well as anassertion that the client application 224 is authorized to access theservice provider 209.

Moving on to step 959, the client application 224 sends the SAMLresponse received from the identity provider 206 to the service providerindicating that the login was successful. The service provider 209 canvalidate or verify the information in the SAML response and then grantthe client application 224 access to the service provider 209. Referringnext to step 963, the service provider 209 begins to send applicationdata to the client application 224 in response to requests from theclient application 224.

The flowcharts of FIGS. 4-8 and the sequence diagrams of FIG. 3 and FIG.9 show examples of the functionality and operation of implementations ofcomponents described herein. The components described herein can beembodied in hardware, software, or a combination of hardware andsoftware. If embodied in software, each element can represent a moduleof code or a portion of code that includes program instructions toimplement the specified logical function(s). The program instructionscan be embodied in the form of, for example, source code that includeshuman-readable statements written in a programming language or machinecode that includes machine instructions recognizable by a suitableexecution system, such as a processor in a computer system or othersystem. If embodied in hardware, each element can represent a circuit ora number of interconnected circuits that implement the specified logicalfunction(s).

Although the flowcharts and sequence diagram show a specific order ofexecution, it is understood that the order of execution can differ fromthat which is shown. For example, the order of execution of two or moreelements can be switched relative to the order shown. Also, two or moreelements shown in succession can be executed concurrently or withpartial concurrence. Further, in some examples, one or more of theelements shown in the flowcharts can be skipped or omitted.

The client device 203, the device management service 204, the identityprovider 206, the service providers 209, or other components describedherein can include at least one processing circuit. Such a processingcircuit can include, for example, one or more processors and one or morestorage devices that are coupled to a local interface. The localinterface can include, for example, a data bus with an accompanyingaddress/control bus or any other suitable bus structure.

The one or more storage devices for a processing circuit can store dataor components that are executable by the one or more processors of theprocessing circuit. For example, the device management service 204, theidentity provider 206, the service providers 209, the managementapplication 221, the client applications 224, and/or other componentscan be stored in one or more storage devices and be executable by one ormore processors. Also, a data store, such as the identity data store 215or the management data store 213 can be stored in the one or morestorage devices.

The identity provider 206, the device management service 204, theservice providers 209, the management application 221, the clientapplications 224, and/or other components described herein can beembodied in the form of hardware, as software components that areexecutable by hardware, or as a combination of software and hardware. Ifembodied as hardware, the components described herein can be implementedas a circuit or state machine that employs any suitable hardwaretechnology. The hardware technology can include, for example, one ormore microprocessors, discrete logic circuits having logic gates forimplementing various logic functions upon an application of one or moredata signals, application specific integrated circuits (ASICs) havingappropriate logic gates, programmable logic devices (e.g.,field-programmable gate array (FPGAs), and complex programmable logicdevices (CPLDs)).

Also, one or more or more of the components described herein thatinclude software or program instructions can be embodied in anynon-transitory computer-readable medium for use by or in connection withan instruction execution system such as, a processor in a computersystem or other system. The computer-readable medium can contain, store,and/or maintain the software or program instructions for use by or inconnection with the instruction execution system.

A computer-readable medium can include a physical media, such as,magnetic, optical, semiconductor, and/or other suitable media. Examplesof a suitable computer-readable media include, but are not limited to,solid-state drives, magnetic drives, or flash memory. Further, any logicor component described herein can be implemented and structured in avariety of ways. For example, one or more components described can beimplemented as modules or components of a single application. Further,one or more components described herein can be executed in one computingdevice or by using multiple computing devices.

It is emphasized that the above-described examples of the presentdisclosure are merely examples of implementations to set forth for aclear understanding of the principles of the disclosure. Many variationsand modifications can be made to the above-described examples withoutdeparting substantially from the spirit and principles of thedisclosure. All such modifications and variations are intended to beincluded herein within the scope of this disclosure.

Therefore, the following is claimed:
 1. A non-transitorycomputer-readable medium embodying a program executable by a processorof a computing device to cause the computing device to at least: receivea certificate from a client device; generate a ticket-granting ticket;send the ticket-granting ticket to the client device; receive a requestfor a service ticket from the client device, wherein the request for theservice ticket includes the ticket-granting ticket; generate the serviceticket; send the service ticket to the client device; receive theservice ticket from the client device; and send a security assertionmarkup language (SAML) response to the client device, wherein the SAMLresponse provides authentication credentials for a service providerassociated with the service ticket.
 2. The non-transitorycomputer-readable medium of claim 1, wherein the program further causesthe computing device to at least receive a SAML authentication requestfrom the client device.
 3. The non-transitory computer-readable mediumof claim 2, wherein the program further causes the computing device toat least send a Kerberos challenge to the client device in response toreceipt of the SAML authentication request.
 4. The non-transitorycomputer-readable medium of claim 3, wherein: the Kerberos challenge issent as a component of a hypertext transport protocol (HTTP) responsethat comprises a 401 unauthorized status code; and the certificate isreceived from the client device in response to the Kerberos challenge.5. The non-transitory computer-readable medium of claim 1, wherein theprogram further causes the computing device to at least validate thecertificate with an online certificate status protocol (OCSP) service.6. The non-transitory computer-readable medium of claim 5, wherein theticket-granting ticket is generated in response to a validation of thecertificate by the OCSP service.
 7. A system, comprising: a computingdevice comprising a processor and a memory; and machine readableinstructions stored in the memory that, when executed by the processor,cause the computing device to at least: receive a certificate from aclient device; generate a ticket-granting ticket; send theticket-granting ticket to the client device; receive a request for aservice ticket from the client device, wherein the request for theservice ticket includes the ticket-granting ticket; generate the serviceticket; send the service ticket to the client device; receive theservice ticket from the client device; and send a security assertionmarkup language (SAML) response to the client device, wherein the SAMLresponse provides authentication credentials for a service providerassociated with the service ticket.
 8. The system of claim 7, whereinthe machine readable instructions, when executed by the processor,further cause the computing device to at least receive a SAMLauthentication request from the client device.
 9. The system of claim 8,wherein the machine readable instructions, when executed by theprocessor, further cause the computing device to at least send aKerberos challenge to the client device in response to receipt of theSAML authentication request.
 10. The system of claim 9, wherein theKerberos challenge is sent as a component of a hypertext transportprotocol (HTTP) response that comprises a 401 unauthorized status code.11. The system of claim 9, wherein the certificate is received from theclient device in response to the Kerberos challenge.
 12. The system ofclaim 7, wherein the machine readable instructions, when executed by theprocessor, further cause the computing device to at least validate thecertificate with an online certificate status protocol (OCSP) service.13. The system of claim 12, wherein the ticket-granting ticket isgenerated in response to a validation of the certificate by the OCSPservice.
 14. A method, comprising: receiving a certificate from a clientdevice; generating a ticket-granting ticket; sending the ticket-grantingticket to the client device; receiving a request for a service ticketfrom the client device, wherein the request for the service ticketincludes the ticket-granting ticket; generating the service ticket;sending the service ticket to the client device; receiving the serviceticket from the client device; and sending a security assertion markuplanguage (SAML) response to the client device, wherein the SAML responseprovides authentication credentials for a service provider associatedwith the service ticket.
 15. The method of claim 14, further comprisingreceiving a SAML authentication request from the client device.
 16. Themethod of claim 14, further comprising sending a Kerberos challenge tothe client device in response to receipt of the SAML authenticationrequest
 17. The method of claim 16, wherein the Kerberos challenge issent as a component of a hypertext transport protocol (HTTP) responsethat comprises a 401 unauthorized status code.
 18. The method of claim16, wherein receiving the certificate from the client devcie occurs inresponse to sending the Kerberos challenge to the client device.
 19. Themethod of claim 14, further comprising validating the certificate withan online certificate status protocol (OCSP) service.
 20. The method ofclaim 19, wherein generating the ticket-granting ticket occurs inresponse to validating the certificate with the OCSP service.